Processing payments for an online marketplace

ABSTRACT

Disclosed herein are systems, methods, and computer-readable storage devices for enabling users of mobile devices to load funds onto an account with an online marketplace. Instead of linking a payment card with the account, or requiring users to purchase a plastic card from a retailer, a user enrolls his account with the online marketplace to generate a barcode that can be rendered on the mobile device. The user presents the barcode to a merchant for scanning. The merchant scans the barcode to retrieve a serial number, which is submitted to the online marketplace to uniquely identify the user&#39;s account. Then the user can provide funds to the merchant for loading onto the account, and the merchant can use existing payment infrastructure for processing traditional physical plastic cards for loading funds. This approach avoids costs associated with distributing, manufacturing, and stocking plastic cards, and also saves shelf space at retail locations.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of U.S. application Ser. No.14/195,773, filed on Mar. 3, 2014, the content of which is incorporatedherein by reference in its entirety.

BACKGROUND 1. Technical Field

The present disclosure relates to processing transactions and morespecifically to enabling users to complete transactions for an onlinemarketplace using a mobile device without purchasing a physical giftcard or other physical object at a point of sale.

2. Introduction

The majority of mobile operating systems, and an increasing number ofnon-mobile operating systems, provide access to an online marketplacefor users to purchase music, movies, software, upgrades, in-app content,and so forth. Users can add funds to their accounts for such onlinemarketplaces in a number of ways. For example, many device owners addfunds directly on the device via an associated credit or debit account.However, many users either can not or choose not to register a credit ordebit account with the online marketplace. Such users can includechildren or teenagers, users in countries where such accounts are notwidely accepted, or users who are simply leery of sharing their creditor debit account information.

These users can go to a store, purchase a gift card for the onlinemarketplace using the payment method of their choice, and use that giftcard to load funds on the account with the online marketplace. However,this approach has several disadvantages. For example, the entityoperating the online marketplace must manufacture, track, and distributephysical items, such as plastic cards. These all have associatedmanagerial and financial costs. Further, merchants must keep thesephysical items in stock to make sales, which occupies valuable shelfspace, often at prime retail locations near the check-out counters. Thisapproach also wastes a large amount of plastic and other shipping andpackaging materials.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example transaction environment;

FIG. 2 illustrates an example enrollment interaction between a user andan online marketplace server;

FIG. 3 illustrates an example purchase interaction in the exampletransaction environment;

FIG. 4 illustrates an example user interface on a mobile device;

FIG. 5 illustrates an example method embodiment for enrolling a user;

FIG. 6 illustrates an example method embodiment for processing atransaction from the standpoint of a merchant;

FIG. 7 illustrates an example method embodiment for processing atransaction from the standpoint of an online marketplace server; and

FIG. 8 illustrates an example system embodiment.

DETAILED DESCRIPTION

Disclosed herein are systems and methods for allowing a user to loadfunds onto an account with an online marketplace without purchasing aphysical item. The user presents to a point of sale device, amachine-readable code, such as a barcode rendered on a display of his orher mobile device. The point of sale device can scan themachine-readable code, and use existing transaction processinginfrastructure for processing physical cards for payment to transmit aserial number to the online marketplace to initiate the transaction.Users do not need to purchase a plastic card from a merchant, andinstead only present their mobile device, such as smartphone or tablet,to be scanned at the point of sale. Further, this approach can enhancecustomer convenience because customers do not have to scratch off acard, and enter a lengthy serial number. This approach can also reducecustomer support costs due to events such as physical card scratch offcode problems or lost or stolen cards. Further, this approach canenhance customer convenience because customers do not have to scratchoff a protective coating on the card to reveal the redemption code andsubsequently enter a lengthy redemption code at the online marketplace.Users can then load funds into their accounts with the onlinemarketplace from any merchant location that is a reseller for the onlinemarketplace.

Various embodiments of the disclosure are described in detail below.While specific implementations are described, it should be understoodthat this is done for illustration purposes only. Other components andconfigurations may be used without parting from the spirit and scope ofthe disclosure.

FIG. 1 illustrates an example transaction environment 100. In thisenvironment 100, a user 102 presents, via a mobile device 104, a uniquepass with a barcode to be scanned at point of sale 106. The retailer atthe point of sale 106 scans the unique pass, such as via an opticalscanner. The mobile device 104 can alternatively present the unique passto the retailer via near-field communications (NFC) or some othercommunication medium. The unique pass can be encoded for display on ascreen such as via a linear barcode, a two-dimensional or matrix barcode, or a scannable image or text. The user 102 decides how much moneyto add to his or her account with the online marketplace, and providespayment for that amount at the point of sale 106 via a cash, check,credit or debit card, or other payment transaction. The point of sale106 device communicates, via a payment network 110, with an onlinemarketplace server 108 to complete the transaction. When the transactionis complete, the funds are available immediately for use in the accountof the user 102, for purchases via the mobile device 104.

For example, the user 102 can present an iPhone as the mobile device 104with a barcode rendered on the display, such as in an app that managesvarious coupons, tickets, loyalty cards, and other secure documents orbarcodes. The retailer scans the barcode presented on the user's iPhoneat the point of sale 106. The user 102 asks the merchant to load $40.00on her iTunes account and tenders $40.00 as payment. The user can tenderthe $40.00 using any payment means available at the point of sale,including cash. The merchant accesses the online marketplace server 108via existing hardware and software payment infrastructure using a serialnumber identified from the barcode to load the $40.00 onto the user'siTunes account. The online marketplace server 108 updates the user'saccount balance, making the funds available for immediate use. Theonline marketplace server 108 can provide an indication of success tothe point of sale 106 and can also send a notification to the user'siPhone. This approach can open a new distribution channel for loadingfunds onto accounts with the online marketplace server 108 without thecost and complexities of a physical card.

In one variation, the user 102 enrolls prior to using this paymentapproach. FIG. 2 illustrates an example enrollment interaction 200between a user and an online marketplace server that occurs prior to apayment transaction. The user 102 can open an enrollment app or anenrollment dialog of an app on a smartphone or other mobile device 104.The mobile device 104 provides account details 202 to the onlinemarketplace server 108. The account details can include a username,password, unique identifier of the device 104, a unique accountidentifier, or some other information. The account details can betransmitted via or after challenge-response authentication. The onlinemarketplace server 108 can assign a marketplace serial number 204 to anaccount indicated by the account details 202, and transmit that serialnumber 204 to the mobile device 104. The online marketplace server 108can store this serial number 204 and account pair in a database. Theserial number may be the same as the unique account identifier, but insome embodiments the serial number is completely different, and is onlycorrelated to the account in a database accessible to the onlinemarketplace server 108. Without this database, the serial number wouldbe meaningless and would not contain or represent any usefulinformation.

In one variation, the mobile device 104 uses the serial number 204 togenerate a barcode encoding the serial number 206. The mobile device 104can generate the barcode upon receiving the serial number 206, or canreceive and store the serial number 206 and generate the barcode 206on-demand. For example, the mobile device 104 can encode the serialnumber in different types of barcodes for different types of scanningequipment or for different merchant scenarios. The mobile device 104 cangenerate the barcode with an embedded timestamp which limits the barcodeto being used within a specific period of time.

The online marketplace server 108 can alternatively encode the serialnumber 204 in a barcode and transmit the barcode to the mobile device104. In this approach, the mobile device 104 does not generate thebarcode, but simply stores the image of the barcode and displays thebarcode upon request from the user 102.

FIG. 3 illustrates an example purchase interaction 300 in the exampletransaction environment 100. At step 1, the user causes the mobiledevice 104 to render a barcode 302 on the display and presents thebarcode 302 to the point of sale 106 for scanning. At step 2, themerchant enters an amount 304 to load onto the user's account. At step3, the user provides payment of the amount 306. At step 4, the point ofsale 106 submits transaction details 308 to the online marketplaceserver 108 via the existing payment network 110 infrastructure. Thetransaction details can include an amount, a serial number extractedfrom the barcode 302, a payment method, a timestamp, a deviceidentifier, a device type, or any other information gathered by themerchant or encoded in the barcode 302. The online marketplace server108 can optionally send a confirmation 310 to the point of sale 106. Theonline marketplace server 108 can also optionally push a notification tothe mobile device 104 that the funds have been loaded. The notificationcan be an email or text message, or can be a notification pushed via anetwork to a specific app or to the operating system of the mobiledevice 104. The notification can be stored in the online marketplace, sothe user receives the notification the next time he or she opens theonline marketplace portal on the mobile device 104 or at any otherlocation, such as a desktop computer.

In one variation, when the user 102 uses the barcode to load funds ontohis or her account, the barcode remains the same. In another variation,when the user 102 uses the barcode to load funds onto his or heraccount, the online marketplace server 108 can modify the barcode or theserial number, such as incrementing a counter in the barcode orincrementing a counter in a portion of the serial number, and transmitan updated barcode or an updated serial number to the mobile device 104(or to multiple registered mobile devices).

FIG. 4 illustrates an example user interface 400 on the mobile device104. This example user interface 400 includes a name 402 of the account,the barcode 404, and an account balance 406. The name 402 allows theuser to quickly determine that the barcode is for the desired account.The user interface 400 can include a barcode 404 such as a QR code, alinear barcode, or some other barcode. The user interface 400 caninclude multiple barcodes, or can allow the user to swipe back and forthbetween different barcodes or otherwise select one of a set of barcodes.Alternatively, the device can determine, based on location data, towhich retailer the device is likely being presented for scanning, andautomatically select a barcode type to display for known capabilities ofscanning equipment at that retailer location. The account balance 406can update dynamically to reflect purchases in the online marketplace aswell as funds loaded onto the account. Because the barcode does nottypically encode the account balance, an updated account balance 406would not necessarily lead to a change in the barcode.

The mobile device 104 can provide location data via the barcode. Thenthe online marketplace server 108 can perform additional authenticationbased on the location data. An app on the mobile device 104 can furtherincorporate account authentication when generating the barcode. Theonline marketplace server 108 can manage push notifications, comparingand authenticating mobile devices based on location data, trackingaccount balances, encoding data into barcodes, incorporating digitalsignatures into barcodes, and so forth.

The mobile device 104 can have different software plugins or modules forgenerating different types of barcodes. For example, an app can rely onthe same underlying logic, while providing a different barcode fordifferent regions. For example, if QR codes are more popular withretailers in Japan, the app can use or retrieve a module for generatingQR codes based on location when in Japan. Similarly, when in Canada, theapp can determine that linear UPC barcodes are more popular and canretrieve and use a module for generating linear UPC barcodes. Thisapproach can further apply to individual merchants, so that the apprenders a barcode or other machine-readable code for a specificretailer, when the location data of the mobile device 104 indicates thatthe user is at the specific retailer.

The mobile device 104 can provide instructions for how to load fundsonto the account with the online marketplace, especially for users whohave not loaded funds before, or who do not already have an associatedpayment account. The mobile device 104 or the online marketplace canprovide these instructions when the account balance is below athreshold, or when the user is within a threshold distance from alocation that can load funds onto the account by scanning a barcode.Similarly, the mobile device 104 can incorporate a location based alertto wake the mobile phone 104 up when within the threshold distance, andautomatically display the barcode, whether by opening an app or bytemporarily changing a wallpaper of the mobile device lock screen, forexample.

The mobile device 104 can determine location data based on GPS signalsand latitude and longitude coordinates. The mobile device 104 or theonline marketplace server 108 can then compare the coordinates to adatabase of known merchants and point of sale locations. Alternatively,a merchant can install a Wi-Fi transmitter or other wireless device thatprovides an identifier to the mobile device 104 indicating a location ofthe mobile device. This approach can be helpful for mobile devices thatare not always connected or do not have GPS hardware, such as portablemusic players or tablets. For example, a merchant can install aBluetooth™ puck that broadcasts location data or a location identifierthat the mobile device 104 can use when generating a barcode to bescanned for a transaction with the online marketplace server 108.

Having disclosed some basic system components and concepts, thedisclosure now turns to the exemplary method embodiments shown in FIGS.5-7. For the sake of clarity, each of the methods is described in termsof an exemplary system 800 as shown in FIG. 8 configured to practice therespective method. The steps outlined herein are exemplary and can beimplemented in any combination thereof, including combinations thatexclude, reorder, add, or modify certain steps.

FIG. 5 illustrates an example method embodiment for enrolling a user.The system receives, from a user device and at an authentication serverof an online marketplace, an enrollment request, wherein the enrollmentrequest identifies a user account with the online marketplace, the useraccount existing prior to the enrollment request (502). An app formanaging bar codes from multiple sources on the user device can generateand transmit the enrollment request. The system can further receive,from the user device and at the authentication server of an onlinemarketplace, additional account details as part of the enrollmentrequest, and confirm the additional account details as part of anauthentication routine.

In response to the enrollment request, the system can associate a serialnumber with the user account (504). The system can determine that anexisting serial number has been associated with the user account priorto the enrollment request, and transmit the existing serial number tothe user device instead of generating an entirely new serial number. Inone aspect, a single serial number is used for all devices associatedwith the user account, while in another aspect, each device associatedwith the user account is associated with a different serial number. Oneuser account can be associated with multiple serial numbers either inseries or at the same time.

The system can transmit the serial number to the user device foridentifying the user account at a point of sale terminal (506). Thesystem can transmit the serial number in plain text, as an encryptedmessage, encoded in an image of a machine-readable code, or asinstructions for generating a machine-readable code. Themachine-readable code can be an image for rendering on a display, or themachine readable code can be a specially formed text or image string.The machine-readable code can also include non-visual codes, such as anaudio signal or a wireless transmission such as communication via NFCdevices.

FIG. 6 illustrates an example method embodiment for processing atransaction from the standpoint of a merchant. The system can scan amachine-readable code presented on a display of a mobile device (602).The machine-readable code can be a quick response (QR) code, a linearbarcode, a two dimensional barcode, or a matrix barcode, for example.The mobile device can present other types of visual and/or non-visualmachine-readable codes.

The system can identify, from the machine-readable code, a serial numberassociated with a user account of an online marketplace (604). Thesystem can receive payment of an amount of money (606). For example, thesystem can prompt a store clerk to enter the amount of money. The usercan provide verbal instructions regarding the amount of money or canenter the amount on a keypad on the point of sale equipment, or via themobile device itself.

The system can transmit to the online marketplace the serial number andan indication of the amount of money as part of a payment transactionfor applying the amount of money to the user account (608). The systemcan further identify, from the machine-readable code, location data ofthe mobile device, and transmit the location data to the onlinemarketplace. The system can receive a confirmation of the paymenttransaction (610). In one variation, the system receives, from theonline marketplace, a balance of the user account, and determines atop-up amount based on the balance. Then the system can suggest thetop-up amount as the amount of money to load onto the account. Forexample, the system can determine an amount that is greater than $20.00that, if added to the balance, would total the next even multiple of$5.00. If the user has a balance of $13.29, the system can suggest atop-up amount of $21.71 to reach a total of $35.00. The exact rules forsuggesting top-up amounts may vary, and can be user-configurable. If theuser does not configure settings for making top-up amountrecommendations, the system can apply system defaults. Further, the usercan enable or disable such top-up recommendations altogether.

FIG. 7 illustrates an example method embodiment for processing atransaction from the standpoint of an online marketplace server. Thesystem can receive, from a point of sale device and as part of a requestto process a payment transaction, a serial number and an indication ofan amount of money, wherein the serial number was obtained by scanning amachine-readable code presented on a display of a mobile device (702).In one embodiment, the online marketplace provided the machine-readablecode to the mobile device.

The system can identify, based on the serial number, a user account ofan online marketplace (704). The serial number can be associated with auser account of the mobile device, or with a second user account otherthan the user account with which the serial number is associated. Whenthe serial number is associated with a second user account, the systemcan receive an indication of an amount of credit to transfer from thesecond user account to the user account, and transfer the amount ofcredit from the second user account to the user account. This can enablea user to transfer credit between accounts, such as a parent managingcredit among children's accounts, or such as a friend giving a gift.

When giving a gift of a transfer of credit from one user account toanother user account, the barcode can encode additional information suchas a message or electronic card from the giver to the recipient. Theadditional information can include instructions to the onlinemarketplace server 108 for how or when to deliver the transfer ofcredit. Alternatively, this additional information can be gathered viaan app on the mobile device 104 and transmitted separately to the onlinemarketplace server 108 with an identifier for matching up the additionalinformation with a specific transaction. Then the online marketplaceserver 108 can match the message with the transaction, and push anotification to a mobile device of the recipient, including at leastpart of the additional message.

The system can receive from the point of sale device a paymentassociated with the payment transaction (706) and apply the amount ofmoney to the user account of the online marketplace (708). The systemcan transmit, to the point of sale device, a confirmation of the paymenttransaction (710). The system can also push a notification to the mobiledevice of the confirmation of the payment transaction. The notificationcan be a pop-up or email, for example. However, in one variation, thesystem pushes a notification to the mobile device that simply updatesthe balance 406, such as in the example user interface 400 of FIG. 4. Inthis way, the user can simply watch the user interface 400 and confirmthat the transaction was successful simply based on the updated balance406.

In yet another embodiment describing the mobile device presenting thebarcode at the point of sale, the system can receive, at a mobiledevice, a request to initiate a payment transaction for a user accountwith an online marketplace. The system can retrieve, from a memory ofthe mobile device, a serial number associated with the user account.Then system can generate a machine-readable code storing the serialnumber. The system can present, on a display of the mobile device, themachine-readable code to be scanned by a point of sale device as part ofthe payment transaction. The machine-readable code can encode additionaldata including at least one of location data, user account data,credentials, an amount associated with the payment transaction, atimestamp, or a personal identification number (PIN). The serial numbercan be associated with the user account during an enrollment processprior to the request to initiate the payment transaction.

A brief description of a basic general purpose system or computingdevice in FIG. 8 which can be employed to practice the concepts,methods, and techniques is disclosed below. With reference to FIG. 8, anexemplary system and/or computing device 800 includes a processing unit(CPU or processor) 820 and a system bus 810 that couples various systemcomponents including the system memory 830 such as read only memory(ROM) 840 and random access memory (RAM) 850 to the processor 820. Thesystem 800 can include a cache 822 of high-speed memory connecteddirectly with, in close proximity to, or integrated as part of theprocessor 820. The system 800 copies data from the memory 830 and/or thestorage device 860 to the cache 822 for quick access by the processor820. In this way, the cache provides a performance boost that avoidsprocessor 820 delays while waiting for data. These and other modules cancontrol or be configured to control the processor 820 to perform variousoperations or actions. Other system memory 830 may be available for useas well. The memory 830 can include multiple different types of memorywith different performance characteristics. It can be appreciated thatthe disclosure may operate on a computing device 800 with more than oneprocessor 820 or on a group or cluster of computing devices networkedtogether to provide greater processing capability. The processor 820 caninclude any general purpose processor and a hardware module or softwaremodule, such as module 1 862, module 2 864, and module 3 866 stored instorage device 860, configured to control the processor 820 as well as aspecial-purpose processor where software instructions are incorporatedinto the processor. The processor 820 may be a self-contained computingsystem, containing multiple cores or processors, a bus, memorycontroller, cache, etc. A multi-core processor may be symmetric orasymmetric. The processor 820 can include multiple processors, such as asystem having multiple, physically separate processors in differentsockets, or a system having multiple processor cores on a singlephysical chip. Similarly, the processor 820 can include multipledistributed processors located in multiple separate computing devices,but working together such as via a communications network. Multipleprocessors or processor cores can share resources such as memory 830 orthe cache 822, or can operate using independent resources. The processor820 can include one or more of a state machine, an application specificintegrated circuit (ASIC), or a programmable gate array (PGA) includinga field PGA.

The system bus 810 may be any of several types of bus structuresincluding a memory bus or memory controller, a peripheral bus, and alocal bus using any of a variety of bus architectures. A basicinput/output (BIOS) stored in ROM 840 or the like, may provide the basicroutine that helps to transfer information between elements within thecomputing device 800, such as during start-up. The computing device 800further includes storage devices 860 or computer-readable storage mediasuch as a hard disk drive, a magnetic disk drive, an optical disk drive,tape drive, solid-state drive, RAM drive, removable storage devices, aredundant array of inexpensive disks (RAID), hybrid storage device, orthe like. The storage device 860 can include software modules 862, 864,866 for controlling the processor 820. The system 800 can include otherhardware or software modules. The storage device 860 is connected to thesystem bus 810 by a drive interface. The drives and the associatedcomputer-readable storage devices provide nonvolatile storage ofcomputer-readable instructions, data structures, program modules andother data for the computing device 800. In one aspect, a hardwaremodule that performs a particular function includes the softwarecomponent stored in a tangible computer-readable storage device inconnection with the necessary hardware components, such as the processor820, bus 810, display 870, and so forth, to carry out a particularfunction. In another aspect, the system can use a processor andcomputer-readable storage device to store instructions which, whenexecuted by the processor, cause the processor to perform operations, amethod or other specific actions. The basic components and appropriatevariations can be modified depending on the type of device, such aswhether the device 800 is a small, handheld computing device, a desktopcomputer, or a computer server. When the processor 820 executesinstructions to perform “operations”, the processor 820 can perform theoperations directly and/or facilitate, direct, or cooperate with anotherdevice or component to perform the operations.

Although the exemplary embodiment(s) described herein employs the harddisk 860, other types of computer-readable storage devices which canstore data that are accessible by a computer, such as magneticcassettes, flash memory cards, digital versatile disks (DVDs),cartridges, random access memories (RAMs) 850, read only memory (ROM)840, a cable containing a bit stream and the like, may also be used inthe exemplary operating environment. Tangible computer-readable storagemedia, computer-readable storage devices, or computer-readable memorydevices, expressly exclude media such as transitory waves, energy,carrier signals, electromagnetic waves, and signals per se.

To enable user interaction with the computing device 800, an inputdevice 890 represents any number of input mechanisms, such as amicrophone for speech, a touch-sensitive screen for gesture or graphicalinput, keyboard, mouse, motion input, speech and so forth. An outputdevice 870 can also be one or more of a number of output mechanismsknown to those of skill in the art. In some instances, multimodalsystems enable a user to provide multiple types of input to communicatewith the computing device 800. The communications interface 880generally governs and manages the user input and system output. There isno restriction on operating on any particular hardware arrangement andtherefore the basic hardware depicted may easily be substituted forimproved hardware or firmware arrangements as they are developed.

For clarity of explanation, the illustrative system embodiment ispresented as including individual functional blocks including functionalblocks labeled as a “processor” or processor 820. The functions theseblocks represent may be provided through the use of either shared ordedicated hardware, including, but not limited to, hardware capable ofexecuting software and hardware, such as a processor 820, that ispurpose-built to operate as an equivalent to software executing on ageneral purpose processor. For example the functions of one or moreprocessors presented in FIG. 8 may be provided by a single sharedprocessor or multiple processors. (Use of the term “processor” shouldnot be construed to refer exclusively to hardware capable of executingsoftware.) Illustrative embodiments may include microprocessor and/ordigital signal processor (DSP) hardware, read-only memory (ROM) 840 forstoring software performing the operations described below, and randomaccess memory (RAM) 850 for storing results. Very large scaleintegration (VLSI) hardware embodiments, as well as custom VLSIcircuitry in combination with a general purpose DSP circuit, may also beprovided.

The logical operations of the various embodiments are implemented as:(1) a sequence of computer implemented steps, operations, or proceduresrunning on a programmable circuit within a general use computer, (2) asequence of computer implemented steps, operations, or proceduresrunning on a specific-use programmable circuit; and/or (3)interconnected machine modules or program engines within theprogrammable circuits. The system 800 shown in FIG. 8 can practice allor part of the recited methods, can be a part of the recited systems,and/or can operate according to instructions in the recited tangiblecomputer-readable storage devices. Such logical operations can beimplemented as modules configured to control the processor 820 toperform particular functions according to the programming of the module.For example, FIG. 8 illustrates three modules Mod1 862, Mod2 864 andMod3 866 which are modules configured to control the processor 820.These modules may be stored on the storage device 860 and loaded intoRAM 850 or memory 830 at runtime or may be stored in othercomputer-readable memory locations.

One or more parts of the example computing device 800, up to andincluding the entire computing device 800, can be virtualized. Forexample, a virtual processor can be a software object that executesaccording to a particular instruction set, even when a physicalprocessor of the same type as the virtual processor is unavailable. Avirtualization layer or a virtual “host” can enable virtualizedcomponents of one or more different computing devices or device types bytranslating virtualized operations to actual operations. Ultimatelyhowever, virtualized hardware of every type is implemented or executedby some underlying physical hardware. Thus, a virtualization computelayer can operate on top of a physical compute layer. The virtualizationcompute layer can include one or more of a virtual machine, an overlaynetwork, a hypervisor, virtual switching, and any other virtualizationapplication.

The processor 820 can include all types of processors disclosed herein,including a virtual processor. However, when referring to a virtualprocessor, the processor 820 includes the software components associatedwith executing the virtual processor in a virtualization layer andunderlying hardware necessary to execute the virtualization layer. Thesystem 800 can include a physical or virtual processor 820 that receiveinstructions stored in a computer-readable storage device, which causethe processor 820 to perform certain operations. When referring to avirtual processor 820, the system also includes the underlying physicalhardware executing the virtual processor 820.

Embodiments within the scope of the present disclosure may also includetangible and/or non-transitory computer-readable storage devices forcarrying or having computer-executable instructions or data structuresstored thereon. Such tangible computer-readable storage devices can beany available device that can be accessed by a general purpose orspecial purpose computer, including the functional design of any specialpurpose processor as described above. By way of example, and notlimitation, such tangible computer-readable devices can include RAM,ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storageor other magnetic storage devices, or any other device which can be usedto carry or store desired program code in the form ofcomputer-executable instructions, data structures, or processor chipdesign. When information or instructions are provided via a network oranother communications connection (either hardwired, wireless, orcombination thereof) to a computer, the computer properly views theconnection as a computer-readable medium. Thus, any such connection isproperly termed a computer-readable medium. Combinations of the aboveshould also be included within the scope of the computer-readablestorage devices.

Computer-executable instructions include, for example, instructions anddata which cause a general purpose computer, special purpose computer,or special purpose processing device to perform a certain function orgroup of functions. Computer-executable instructions also includeprogram modules that are executed by computers in stand-alone or networkenvironments. Generally, program modules include routines, programs,components, data structures, objects, and the functions inherent in thedesign of special-purpose processors, etc. that perform particular tasksor implement particular abstract data types. Computer-executableinstructions, associated data structures, and program modules representexamples of the program code means for executing steps of the methodsdisclosed herein. The particular sequence of such executableinstructions or associated data structures represents examples ofcorresponding acts for implementing the functions described in suchsteps.

Other embodiments of the disclosure may be practiced in networkcomputing environments with many types of computer systemconfigurations, including personal computers, hand-held devices,multi-processor systems, microprocessor-based or programmable consumerelectronics, network PCs, minicomputers, mainframe computers, and thelike. Embodiments may also be practiced in distributed computingenvironments where tasks are performed by local and remote processingdevices that are linked (either by hardwired links, wireless links, orby a combination thereof) through a communications network. In adistributed computing environment, program modules may be located inboth local and remote memory storage devices.

The various embodiments described above are provided by way ofillustration only and should not be construed to limit the scope of thedisclosure. Various modifications and changes may be made to theprinciples described herein without following the example embodimentsand applications illustrated and described herein, and without departingfrom the spirit and scope of the disclosure. Claim language reciting “atleast one of” a set indicates that one member of the set or multiplemembers of the set satisfy the claim.

What is being claimed is:
 1. A method for generating a machine readable code, the method comprising: transmitting, over a network to a server, a request to generate a machine reachable code associated with a user account; receiving, over the network from the server, a unique code associated with the user account and assigned by the server; generating, at a mobile device, the machine readable code based on the unique code, the machine readable code including the unique code and additional data; presenting, at a terminal, the machine readable code to process a transaction to apply a payment amount to the user account; in response to the transaction being processed, receiving, at the mobile device, a notification the transaction was successful.
 2. The method of claim 1, wherein the additional data including at least one of location data, user account data, authentication credentials, an amount associated with the payment transaction, a device identifier, a device type, a timestamp, or a personal identification number (PIN).
 3. The method of claim 1, wherein the additional data is an embedded timestamp which limits the machine readable code to being used within a specific period of time.
 4. The method of claim 1, further comprising: in response to the transaction being processed, receiving, over the network from the server, an updated unique code, wherein the updated unique code replaces the unique code; and generating, at the mobile device, an updated machine readable code based on the updated unique code, the updated machine readable code including the updated unique code and updated additional data.
 5. The method of claim 1, wherein a type of the machine readable code is based on a location of the terminal.
 6. The method of claim 1, wherein the additional data is location data of the mobile device, and, in response to the transaction being processed, receiving, at the mobile device, a notification additional authentication based on the location data was successful.
 7. The method of claim 1, wherein the machine-readable code comprises at least one of a quick response (QR) code, a linear barcode, a two dimensional barcode, or a matrix barcode.
 8. The method of claim 1, further comprising: presenting, on a display of the mobile device, a balance of the user account.
 9. A device for generating a machine readable code, the device comprising: a processor; and a memory storing instructions, which when executed by the processor, causes the processor to: transmit, over a network to a server, a request for a machine reachable code associated with a user account; receive, over the network from the server, a unique code associated with the user account and assigned by the server; generate the machine readable code based on the unique code, the machine readable code including the unique code and additional data; present, at a terminal, the machine readable code to process a transaction to apply a payment amount to the user account; in response to the transaction being processed, receiving a notification the transaction was successful.
 10. The device of claim 9, wherein the additional data including at least one of location data, user account data, authentication credentials, an amount associated with the payment transaction, a device identifier, a device type, a timestamp, or a personal identification number (PIN).
 11. The device of claim 9, wherein the additional data is an embedded timestamp which limits the machine readable code to being used within a specific period of time.
 12. The device of claim 9, wherein the memory further storing instructions, which when executed by the processor causes the processor to: in response to the transaction being processed, receive, over the network from the server, an updated unique code, wherein the updated unique code replaces the unique code; and generate, an updated machine readable code based on the updated unique code, the updated machine readable code including the updated unique code and updated additional data.
 13. The device of claim 9, wherein a type of the machine readable code is based on a location of the terminal.
 14. The device of claim 9, wherein the additional data is location data of the device, and, the memory further storing instructions, which when executed by the processor causes the processor to: in response to the transaction being processed, receive, a notification additional authentication based on the location data was successful.
 15. The device of claim 9, wherein the machine-readable code comprises at least one of a quick response (QR) code, a linear barcode, a two dimensional barcode, or a matrix barcode.
 16. The device of claim 9, further comprising: presenting, on a display, a balance of the user account.
 17. A non-transitory computer readable medium storing instructions, which when executed by a processor of a device, causes the processor to: transmit, over a network to a server, a request for a machine reachable code associated with a user account; receive, over the network from the server, a unique code associated with the user account and assigned by the server; generate the machine readable code based on the unique code, the machine readable code including the unique code and additional data; present, at a terminal, the machine readable code to process a transaction to apply a payment amount to the user account; in response to the transaction being processed, receiving a notification the transaction was successful.
 18. The non-transitory computer readable medium of claim 17, wherein the additional data including at least one of location data, user account data, authentication credentials, an amount associated with the payment transaction, a device identifier, a device type, a timestamp, or a personal identification number (PIN).
 19. The non-transitory computer readable medium of claim 17, wherein the memory further storing instructions, which when executed by the processor causes the processor to: in response to the transaction being processed, receive, over the network from the server, an updated unique code, wherein the updated unique code replaces the unique code; and generate, an updated machine readable code based on the updated unique code, the updated machine readable code including the updated unique code and updated additional data.
 20. The non-transitory computer readable medium of claim 17, wherein the machine-readable code comprises at least one of a quick response (QR) code, a linear barcode, a two dimensional barcode, or a matrix barcode. 